home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-126 < prev    next >
Text File  |  1988-12-01  |  33KB  |  710 lines
  1.  
  2. IEN 126                                                      Danny Cohen
  3.                                                            U S C / I S I
  4.                                                            November 1979
  5.  
  6.  
  7.  
  8.              SUMMARY OF THE ARPA/ETHERNET COMMUNITY MEETING
  9.  
  10.  
  11. On  Thursday,  October  18th,  1979, a meeting was held at Xerox-PARC to
  12. discuss  the  support  of  ETHERNET  based  communication  in  the  ARPA
  13. sponsored internetwork environment (INE).
  14.  
  15. The following participated in the meeting:
  16.  
  17.    - CMU (Bob Sproull)
  18.  
  19.    - ISI (Danny Cohen)
  20.  
  21.    - MIT-LCS (Dave Clark)
  22.  
  23.    - Stanford University (Forest Baskett, John Seamas, Bill Nowicki)
  24.  
  25.    - University of Rochester (Ed Burke)
  26.  
  27.    - Xerox-PARC (Ed Taft, Mike Schroeder, Ron Crane, John Shoch)
  28.  
  29. It turned out that Caltech, which is another ARPA site, already has four
  30. ALTOs and an Ethernet.  They were not represented in this  meeting,  and
  31. probably should be made part of this ARPA/Ethernet community.
  32.  
  33. The  group  reached  an  agreement about the way to support both IP- and
  34. PUP-based communication in such a way that the richness of  both  worlds
  35. is  preserved.    This  can  be  encapsulated in the following:  when in
  36. conflict, use IP as a transport (hence, lower level) protocol for PUP.
  37.  
  38. A detailed discussion of this issue follows, in (A) below.
  39.                                                                   Page 2
  40.  
  41. One cannot over-emphasize that this effort is NOT aimed  to  provide  an
  42. automatic  translation/conversion between the IP-based and the PUP-based
  43. software,  but  to  support  coexistence  and  mutual  support  of  both
  44. communication  regimes.    Providing  that conversion service is a noble
  45. goal, but unfortunately is too complicated to be considered as a part of
  46. this effort  because  it  involves  complicated  technical  issues  like
  47. addresses in a non-uniform set of internetwork environments.
  48.  
  49. However,  even though no automatic direct conversion is provided between
  50. these regimes, a certain degree of compatibility  and  inter-operability
  51. exists  due  to hosts which "talk" both "languages".  This capability is
  52. provided by the ability to transfer files back and forth between the IP-
  53. and the PUP-worlds, to forward mail, to cascade TELNET connections,  and
  54. the like.
  55.  
  56. In  addition,  the  existence  of PUP-based Xerox products (like Dovers,
  57. ALTOs and Penguins) in the ARPA community requires, to a certain degree,
  58. the ability to support PUP communication among sites which are already a
  59. part of the IP-internet, without requiring them also to  participate  in
  60. the PUP-internet.
  61.  
  62. Basically   the   entire  group  agreed  to  work  toward  communication
  63. compatibility and effort sharing.
  64.  
  65. Since there is a great deal of commonality of both hardware and software
  66. requirements among the sites,  we  expect  to  be  able  to  share  both
  67. hardware  and  software  efforts  by  exchanging  and  copying interface
  68. designs, exchange of software, and the like.
  69.  
  70. According to the proposed agreement, the IP-world and the PUP-world  can
  71. coexist in such a way that ARPA maintains complete control of the former
  72. and  Xerox-PARC  of  the  latter.    This  control  is the assignment of
  73. network-IDs, updating of routing-tables, name-servers, etc.
  74.  
  75. Ethernets  may participate in the PUP-world, or serve  just  as  private
  76. local  access  systems,  which  are  not  part  of  any  internetworking
  77. environment.  In either case, the Ethernets may be  totally  transparent
  78. to  the  outside,  while  supporting  traffic  between  IP-hosts, and no
  79. symmetry is required between  the  communicating  sites,  i.e.,  a  site
  80. without  an  Ethernet does not have to be aware that the other site uses
  81. an Ethernet for its local access.
  82.  
  83. The following sections are:
  84.  
  85.   (A) A discussion of the proposed relation between the protocols,
  86.  
  87.   (B) The  hardware/software  components  which  will  probably  be
  88.       developed  at  individual  sites  and made available to other
  89.       participants.  This is a tentative list  and  should  not  be
  90.       viewed as a firm commitment, and
  91.  
  92.   (C) The list of the participants, addresses, etc.
  93.  
  94.                                                                   Page 3
  95.  
  96. (A) IP/PUP Communication
  97.  
  98.  
  99.  
  100. THE PROBLEM
  101.  
  102. Support communication between Ethernet-based systems at different sites,
  103. by  using  either  the  IP-  or  the  PUP-based protocols, over the ARPA
  104. sponsored InterNetwork Environment (INE).
  105.  
  106. This is NOT intended to provide inter-operability  of  these  protocols,
  107. only their co-existence.
  108.  
  109.  
  110.  
  111. APPROACH
  112.  
  113. Both  the  IP and PUP assume that they are the sole level-1 internetwork
  114. protocols.
  115.  
  116. Since the ARPA-sponsored INE already has many gateways which  are  based
  117. on  IP,  we  chose  to encapsulate PUP inside IP for traversing the INE.
  118. Note that this doesn't exclude the dual, namely IP inside PUP.
  119.  
  120. This encapsulation may be performed either by hosts or by gateways.
  121.  
  122. The interaction between IP and PUP is based on the ability  of  each  to
  123. act as the transport for the other.
  124.  
  125. This  is  a slight deviation from our previous simplistic notion of pure
  126. hierarchy of protocols which allows the drawing of nice tree  structures
  127. with unique level-number to each protocol.  Since both IP and PUP can be
  128. either "above" or "below" the other -- strange loops [GEB] may result.
  129.  
  130. It  is  important not to exclude the ability of each IP-host to have its
  131. own  unique  IP-address,  while  each  PUP-host  has  its   own   unique
  132. PUP-address, if so desired, without excluding the ability to have both.
  133.                                                                   Page 4
  134.  
  135. DISCUSSION
  136.  
  137. Sites  which  use  mainly  IP probably are better off by performing this
  138. encapsulation by the hosts, and have a E-IP-A ("pure-IP") gateway.  Here
  139. "E" is the Ethernet protocol and  "A"  is  the  external  transport  net
  140. protocol (e.g.  ARPAnet) which is used to connect this site to the INE.
  141.  
  142. Let's use the notation X<Y to mean that X is a lower level protocol than
  143. the  protocol  Y  and is used as a transport for Y, by encapsulating the
  144. Y-messages inside the X-messages.  If the "<" and ">" are considered  as
  145. arrows,  note that they always point "down", to the lower level protocol
  146. and do not indicate direction of flow.
  147.  
  148. By using this notation the above gateway may  be  described  as  E<IP>A.
  149. Again,  the "arrows" do not indicate direction of flow, but indicate the
  150. encapsulation/decapsulation  of  messages  as  they  flow  through  this
  151. gateway in either direction.
  152.  
  153. According  to  the  philosophy  of  IP  both  the  "E"  and  the "A" are
  154. considered as "local" even though "E" is a local access system  and  "A"
  155. is  a  cross-country  communication  system.    As a matter of fact, all
  156. networks are considered as "local-networks" by this school of thought.
  157.  
  158. In such sites the role of the Ethernet here is to be a  local  transport
  159. (level-0) for the IP traffic.
  160.  
  161. However,  internal  (intra-site)  PUP traffic may avoid the IP entirely,
  162. which is essential if Xerox black-boxes (e.g., Dovers and Penguins)  are
  163. used.    Note  that  PUP  traffic  cannot  leave  this site unless it is
  164. encapsulated in IP by the sending hosts.
  165.  
  166. We refer to such sites as type S1.
  167.  
  168. Sites with only PUP based traffic may  choose  to  implement  E<PUP>IP>A
  169. ("pure-PUP") gateways.  This frees the local hosts from dealing with IP.
  170.  
  171. We expect that only Xerox sites may use such gateways.  We refer to such
  172. sites as type S2.
  173.  
  174. Note  that  PUP traffic cannot be communicated between S1 and S2 easily.
  175. It may be kluged but should be considered as not feasible due mainly  to
  176. addressing problems.
  177.  
  178. Sites  which  have  to  communicate  with  both  S1 and S2 sites have to
  179. implement a combined IP+PUP gateways.  These are  the  S12  type  sites.
  180. The gateways used by these sites are discussed in some detail later.
  181.                                                                   Page 5
  182.  
  183. MORE DISCUSSION
  184.  
  185. An important notion is that even though PUP is always encapsulated in IP
  186. while traversing the INE it may be performed by either the hosts (the S1
  187. way), or by the gateways (the S2 way).
  188.  
  189. In the  S1 way the  IP-communication is addressed to the destination IP-
  190. host (process).  However, the PUP-communication inside it,  if  any,  is
  191. addressed to a PUP-process, using PUP-addresses.
  192.  
  193. In the  S2 way the PUP-communication is addressed  to the PUP-process in
  194. the source-gateway which is expected to perform its own routing  to  the
  195. PUP-process  in  the  gateway  which  is  the  re-entry  point  into the
  196. PUP-world (or the  exit  point  from  the  IP-world).    The  end-to-end
  197. communication is addressed by its PUP-address.
  198.  
  199. The S1 model treats the  Ethernet as a local access scheme,  while IP is
  200. the internetworking regime.
  201.  
  202. The S2 model treats the IP-INE as a single transporting  network,  while
  203. PUP is the internetworking regime.
  204.  
  205. Hence, it is not expected to support communication between S1 and S2.
  206.  
  207. If  we  use  [E(IP)]  to  represent an IP-message encapsulated inside an
  208. Ethernet-message then the function of the S1-gateway is to  perform  the
  209. following  transformation:  [E(IP)]  <=> [A(IP)], where the direction of
  210. the transformation depends on  the  direction  of  the  flow,  from  the
  211. Ethernet into the the ARPAnet, or vice versa.
  212.  
  213. Hence, the function of the S2-gateway is [E(PUP)] <=> [A(IP(PUP))].
  214.  
  215. The S12 gateway is one which can operate in either of these modes.  As a
  216. matter  of  fact,  there is one other mode of operation which is in some
  217. use, treating the ARPAnet as a communication line (level-0) for PUP.
  218.  
  219. This is done by encapsulating PUP  directly  in  ARPAnet  messages,  and
  220. using  link-152  to  designate  this  traffic.  Note: no IP is involved.
  221. This gateway function is represented by [E(PUP)] <=> [A(PUP)].    By the 
  222. way, the [A(IP)] traffic in the ARPAnet is designated by link-155.
  223.  
  224. Hence, a general gateway, which uses an Ethernet for local  access,  has
  225. to support the following:
  226.  
  227.   1. [E(IP)] <=> [A(IP)]
  228.      Encapsulation   of   IP-messages  in  ARPANEt-messages.    The
  229.      IP-address is that of the destination IP-process.
  230.  
  231.   2. [E(PUP)] <=> [A(IP(PUP))]
  232.      Encapsulation of PUP-messages inside IP-messages, encapsulated
  233.      in  ARPANet-messages.    The  PUP-address  is  that   of   the
  234.      destination host, the IP-address is that of the PUP-process in
  235.      the   destination   gateway   which  retrieves  (performs  the
  236.      decapsulation) of PUP from inside IP.
  237.  
  238.   3. [E(PUP)] <=> [A(PUP)].
  239.      Direct encapsulation of PUP-messages inside ARPAnet-messages.
  240.                                                                   Page 6
  241.  
  242. Using the previous notations, where "arrows" indicate the  direction  of
  243. encapsulation/decapsulation  for  the  two-way  flow, the general IP+PUP
  244. gateway can be described by the following diagram:
  245.  
  246.             **********                 ******     **********
  247.             *        <--1-----------1--<    *     *        *
  248.             * Ether- *     *******     * IP >-1,2-> ARPA-  *
  249.    --1,2,3--<  net   *     *     >--2-->    *     *  net   >--1,2,3--
  250.             *        <-2,3-< PUP *     ******     *        *
  251.             *        *     *     >--3----------3-->        *
  252.             **********     *******                **********
  253.  
  254. John Shoch observed that diagrams like this one  (with  or  without  the
  255. arrows)  may  be viewed as if the lines represent messages and the boxes
  256. represent processes, or as if the boxes represent messages and the lines
  257. represent processes (encapsulation/decapsulation).
  258.  
  259.  
  260.  
  261.  
  262. MORE DETAILS and EXAMPLES
  263.  
  264. Let us consider communication between host-A at  site-X  and  host-B  at
  265. site-Y, where at site-X there is an Ethernet whose PUP-address is S, and
  266. at  site-Y there is an Ethernet whose PUP-address is T. Here "host" is a
  267. single process and a "site" is a set  of  hosts  connected  by  a  local
  268. access scheme.
  269.  
  270. Even  though the ARPAnet is mentioned in all the following examples, one
  271. should be able to notice that in most cases  it represents  any  network
  272. which  supports  IP,  i.e., for which IP-gateways are implemented.  Only
  273. the LINKs mentioned below are actually ARPAnet specific.
  274.  
  275. Let's examine the protocol-nestings and encapsulations for FTPs.
  276.  
  277. (1) Encapsulation/decapsulation into IP, by hosts.
  278.  
  279. Two case are discussed in some details, (1.1) transport of  TCP-traffic,
  280. and (1.2) transport of PUP-traffic.
  281.  
  282. Obviously,  the  FTPs of (1.1) and (1.2) differ and cannot talk directly
  283. to each other, but they can communicate indirectly via  a  file  system,
  284. such as MAXC's.
  285.                                                                   Page 7
  286.  
  287. (1.1) FTP above TCP, above IP.
  288.  
  289. This is the case of IP communication, using the Ethernet and the ARPAnet
  290. as part of the IP-INE.
  291.  
  292. The  sender, host-A, generates an IP-message of the form [IP(TCP(FTP))],
  293. carrying the IP-address Y:B,  which  is  encapsulated  in  the  Ethernet
  294. protocol  for  accessing  the  gateway.  Hence, upon leaving host-A, the
  295. message  is  [E(IP(TCP(FTP)))],  with  the   Ethernet-address   of   the
  296. IP-process in the gateway, by setting the Ethernet 8-bit address to that
  297. of  the  Ethernet interface of gateway-X, and setting the PROTOCOL field
  298. to the value 1001-octal, meaning IP-protocol.
  299.  
  300. Upon receiving this message the Ethernet-process examines the  value  of
  301. the PROTOCOL field and recognizes the message as an IP-message.  It then
  302. hands  to  the IP-process the message without the Ethernet header.  This
  303. is the decapsulation of the message from the Ethernet encapsulation.
  304.  
  305. The IP-process finds that the IP-address  of  the  destination  is  Y:B.
  306. After  checking  its  routing-tables  the  IP-process  finds the ARPAnet
  307. address of the first gateway along the INE-route  to  Y. It  may  happen
  308. that  this is also the final one, if Y is also connected directly to the
  309. ARPAnet.
  310.  
  311. Next, the IP-message is encapsulated in an ARPAnet-message, carrying the
  312. ARPAnet-address of that gateway: [A(IP(TCP(FTP)))].
  313.  
  314. Upon arriving at the gateway of site-Y the local-net header is  stripped
  315. off.    This local network is probably the ARPAnet, if Y is connected to
  316. it directly, but may be any  other  network  which  supports  IP.    The
  317. resulting IP-message is handed to the IP-process.
  318.  
  319. Next,  the  IP-message  is  encapsulated  again  in an Ethernet-message,
  320. addressed to host-B, [E(IP(TCP(FTP)))].
  321.  
  322. Upon arriving  at  host-B  the  Ethernet  header  is  removed,  and  the
  323. IP-message  is  recovered and handed to the IP process which hands it to
  324. the TCP process, which hands it to the FTP process.
  325.  
  326. Note that for this scheme to work it is not necessary for site-Y to have
  327. the same type of local-access network (here the Ethernet) as site-X has,
  328. or any other local network.
  329.  
  330. Note also that in this case the Ethernet neither at site-X nor at site-Y
  331. has to have a PUP-address, and it does not have to be  considered  as  a
  332. part of the PUP-based internetwork environment.
  333.  
  334. In summary, the function of the gateway in this case is:
  335.  
  336.                                 [E(IP(TCP(FTP)))] <=> [A(IP(TCP(FTP)))].
  337.                                                                   Page 8
  338.  
  339. (1.2) FTP above BSP above PUP, above IP.
  340.  
  341. This  is the case of PUP-communication, using host encapsulation of PUP-
  342. messages inside IP-messages for transport through the IP-INE.
  343.  
  344. The sender, host-A, generates a PUP-message of the form [PUP(BSP(FTP))],
  345. and encapsulates it in the IP-message [IP(PUP(BSP(FTP)))] which  carries
  346. the  IP-address  Y:B, which is encapsulated in the Ethernet protocol for
  347. accessing the gateway.  Hence,  upon  leaving  host-A,  the  message  is
  348. [E(IP(PUP(BSP(FTP))))],  with  the Ethernet-address of the IP-process in
  349. the gateway, by setting the  Ethernet  8-bit  address  to  that  of  the
  350. Ethernet  interface  of gateway-X, and setting the PROTOCOL field to the
  351. value 1001-octal, meaning IP-protocol.
  352.  
  353.      In some sense, this Ethernet might not be managed as  part  of
  354.      the  PUP-internet,  but  the  hosts had better have valid PUP-
  355.      addresses; the destination process certainly has a PUP-address
  356.      -- that's why we're sending it PUP-messages!
  357.  
  358.      This raises the following question:  how does the FTP  process
  359.      in  the  PUP  destination get the PUP-address to which it will
  360.      send its response?  A possible answer is that the  sender  had
  361.      better  have  used  a  valid  PUP-address, including a PUP-net
  362.      number.
  363.  
  364.      It is important to note that in this case  the  end  processes
  365.      are  still  sending  and  receiving  PUP-messages  and must be
  366.      located within the PUP-internet  address  space,  despite  the
  367.      fact  that the IP encapsulation is done in the end hosts.  The
  368.      INE is being treated as a single PUP  transport  network,  and
  369.      the end hosts are both on the same "network".
  370.  
  371.      The  PUP-address  within a network is only 8 bits, while an IP
  372.      address within any network is 24 bits.   For now,  we  propose
  373.      that  an  ad-hoc  mapping  strategy be employed.  Each IP host
  374.      that implements IP(PUP) encapsulation is assigned a unique PUP
  375.      host number within the IP "network".  IP addresses are derived
  376.      from PUP-addresses by table lookup.   The  table  is  manually
  377.      maintained  (by Xerox-PARC) limited to 256 entries.  We expect
  378.      that only a few hosts will need to communicate in this manner.
  379.  
  380. Upon receiving this message the Ethernet-process in  the  source-gateway
  381. examines  the  value of the PROTOCOL field and recognizes the message as
  382. an IP-message.  It then hands to the IP-process the message without  the
  383. Ethernet  header.    This  is  the decapsulation of the message from the
  384. Ethernet encapsulation.  The IP-process finds that the IP-address of the
  385. destination is Y:B.  After checking its  routing-tables  the  IP-process
  386. finds the ARPAnet address of the first gateway along the INE-route to Y.
  387. It  may happen that  this is also the final one,  if Y is also connected
  388. directly to the ARPAnet.
  389.  
  390. Next, the IP-message is encapsulated in an ARPAnet-message, carrying the
  391. ARPAnet-address of that gateway: [A(IP(PUP(BSP(FTP))))].
  392.                                                                   Page 9
  393.  
  394. Upon arriving at the gateway of site-Y the local-net header is  stripped
  395. off.    This local network is probably the ARPAnet, if Y is connected to
  396. it directly, but may be any  other  network  which  supports  IP.    The
  397. resulting IP-message is handed to the IP-process.
  398.  
  399. Next,  the  IP-message  is  encapsulated  again  in an Ethernet-message,
  400. addressed to host-B, [E(IP(PUP(BSP(FTP))))].
  401.  
  402. Upon arriving  at  host-B  the  Ethernet  header  is  removed,  and  the
  403. IP-message  is recovered and handed to the PUP process which hands it to
  404. the BSP process, which hands it to the FTP process.
  405.  
  406. Note that for this scheme to work it is not necessary for site-Y to have
  407. the same local-access network (here the Ethernet) as site-X has, or  any
  408. other local network.
  409.  
  410. In summary, the function of the gateway in this case is:
  411.  
  412.                       [E(IP(PUP(BSP(FTP))))] <=> [A(IP(PUP(BSP(FTP))))].
  413.  
  414.  
  415.  
  416.  
  417.  
  418. (2) Encapsulation/decapsulation into IP, by gateways.
  419.  
  420. We consider a case of FTP above BSP, above PUP.
  421.  
  422. This  is  the  case of PUP-communication, using gateway encapsulation of
  423. PUP-messages inside IP-messages for transport through the IP-INE.
  424.  
  425. The sender, host-A, generates a PUP-message of the form [PUP(BSP(FTP))],
  426. carrying the PUP-address T:B, which  is  encapsulated  in  the  Ethernet
  427. protocol  for  accessing  the  gateway.  Hence, upon leaving host-A, the
  428. message  is  [E(PUP(BSP(FTP)))],  with  the  Ethernet-address   of   the
  429. PUP-process  in  the  gateway,  by setting the Ethernet 8-bit address to
  430. that of the Ethernet interface of gateway-X, and  setting  the  PROTOCOL
  431. field to the value 1000-octal, meaning PUP-protocol.
  432.  
  433. Upon  receiving  this message the Ethernet-process examines the value of
  434. the PROTOCOL field and recognizes the message as a PUP-message.  It then
  435. hands to the PUP-process the message without the Ethernet header.   This
  436. is  the  decapsulation  of  the message from the Ethernet encapsulation.
  437. The PUP-process finds that the PUP-address of the  destination  is  T:B.
  438. After  checking its routing-tables the PUP-process finds the PUP-address
  439. of the gateway into PUP-network T,  which  is  the  PUP-process  in  the
  440. gateway-Y.  Then it encapsulates the PUP-message [PUP(BSP(FTP))], inside
  441. the   IP-message  [IP(PUP(BSP(FTP)))].    The  protocol  field  of  this
  442. IP-message is set to the value 14-octal to designate this message  as  a
  443. PUP-message.
  444.                                                                  Page 10
  445.  
  446. Next,  this IP-message is given to the IP-process with the IP-address of
  447. the PUP-process in gateway-Y.  After  checking  its  routing-tables  the
  448. IP-process  finds  the  ARPAnet  address  of the first gateway along the
  449. INE-route to Y. As before, it may happen that this  is  also  the  final
  450. one, if Y is also connected directly to the ARPAnet.
  451.  
  452. Next, the IP-message is encapsulated in an ARPAnet-message, carrying the
  453. ARPAnet-address of that gateway: [A(IP(PUP(BSP(FTP))))].
  454.  
  455. Upon  arriving at the gateway of site-Y the local-net header is stripped
  456. off.  This local network is probably the ARPAnet, if Y is  connected  to
  457. it  directly,  but  may  be  any  other  network  which support IP.  The
  458. resulting IP-message is handed to the IP-process  which  recognizes  the
  459. message  as  a PUP message (by the value 14-octal in its PROTOCOL field)
  460. and hands it to the PUP-process of this gateway.
  461.  
  462. However,  if  the  network  can  support  process-addressing,  then  the
  463. IP-address  of  this  message  may  be  that  of  the PUP-process in the
  464. destination  gateway.    Process-addressing  is  like   addressing   the
  465. "fake-host"s  in  the  ARPAnet,  for example.  In this case the PROTOCOL
  466. field of the IP-header does not have to be used to be used at all.
  467.  
  468. Note that there is some possible redundancy here,  the  message  may  be
  469. both  marked  as  a  PUP-message  and  be  addressed to the PUP-process.
  470. Hence, it is possible to use only one of these  two  mechanisms,  either
  471. the  IP-header's  PROTOCOL  field,  or  the  ability to address directly
  472. processes in gateways.
  473.  
  474. The PUP-process has no trouble to figure the exact  Ethernet-address  of
  475. the destination host, T:B.
  476.  
  477. Next,  the  PUP-message  is  encapsulated  again in an Ethernet-message,
  478. addressed to host-B, [E(PUP(BSP(FTP)))].
  479.  
  480. Upon arriving  at  host-B  the  Ethernet  header  is  removed,  and  the
  481. PUP-message is recovered and handed to the BSP process which hands it to
  482. the FTP process.
  483.  
  484. Note  that for such a scheme to work it is absolutely necessary for both
  485. sites to have PUP supporting networks, like the Ethernet, for example.
  486.  
  487. Note  also  that  every gateway of the [E(PUP)] <=> [A(IP(PUP))] variety
  488. must have a PUP-address in the "IP-network" as discussed in 1.2, page 8.
  489. Furthermore,  the gateways must implement the ability to broadcast  PUP-
  490. messages  to all PUP-hosts (or at least  to all other gateways)  in  the
  491. "IP-network" so that PUP-routing information will propagate through that
  492. "network".
  493.  
  494. In summary, the function of the gateway in this case is:
  495.  
  496.                           [E(PUP(BSP(FTP)))] <=> [A(IP(PUP(BSP(FTP))))].
  497.  
  498. Note that in this case, unlike the previous ones, there is a  difference
  499. in the level of nesting between the two sides of this expression. Why?
  500.                                                                  Page 11
  501.  
  502. (3)  The  standard  PUP-internetwork  gateway, treating the Ethernet and
  503.      ARPAnet as independent PUP transport networks.
  504.  
  505. In this case FTP is implemented above BSP above PUP, in an ARPAnet host.
  506.  
  507. This is the case  of  PUP-communication,  using  the  Ethernet  and  the
  508. ARPAnet as part of the PUP system.
  509.  
  510. The   sending   host,   A,   generates   an   PUP-message  of  the  form
  511. [PUP(BSP(FTP))], carrying the PUP-address T:B, which is encapsulated  in
  512. the  Ethernet  protocol  for accessing the gateway.  Hence, upon leaving
  513. host-A, the message is [E(PUP(BSP(FTP)))], with the Ethernet-address  of
  514. the PUP-process in the gateway, by setting the Ethernet 8-bit address to
  515. that  of  the  Ethernet interface of gateway-X, and setting the PROTOCOL
  516. field to the value 1000-octal, meaning PUP-protocol.
  517.  
  518. Upon receiving this message the PUP-process in the gateway  removes  the
  519. Ethernet  header  (hence,  decapsulates  the  message  from the Ethernet
  520. encapsulation) and finds the PUP-address of the destination, T:B.  After
  521. checking its routing tables the PUP-process finds the ARPAnet-address of
  522. the gateway  into  PUP-network  T,  which  is  the  PUP-process  in  the
  523. gateway-Y, which is also directly on the ARPAnet.
  524.  
  525. Then it encapsulates the PUP-message [PUP(BSP(FTP))] inside the ARPAnet-
  526. message  [A(PUP(BSP(FTP)))].   The LINK field of this ARPAnet-message is
  527. set to the value 152 to designate this message as a PUP-message.
  528.  
  529. Upon arriving at site-Y the message the ARPAnet-process recognizes it as
  530. a PUP-message by the value of its LINK field (152), and gives it to  the
  531. PUP-process of this gateway.
  532.  
  533. The  PUP-process  has no trouble to figure the exact Ethernet-address of
  534. the destination host, T:B.
  535.  
  536. Next, the PUP-message is  encapsulated  again  in  an  Ethernet-message,
  537. addressed to host-B, [E(PUP(BSP(FTP)))].
  538.  
  539. Upon  arriving  at  host-B  the  Ethernet  header  is  removed,  and the
  540. PUP-message is recovered and handed to the BSP process which hands it to
  541. the FTP process.
  542.  
  543. Note that both sites must have PUP gateways connected  to  the  ARPAnet;
  544. the  end  hosts  themselves  may  be  anywhere in the PUP-internet.  All
  545. communication in  this  case  is  pure-PUP,  with  no  IP  encapsulation
  546. anywhere.
  547.  
  548. By  the way, the reason for having this type of gateway is to be able to
  549. talk to MAXC  via  the  ARPAnet.    MAXC   speaks   only  pure-PUP,  not
  550. IP-encapsulated PUP, and this isn't likely to change in the near future.
  551.  
  552. In summary, the function of the gateway in this case is:
  553.  
  554.                               [E(PUP(BSP(FTP)))] <=> [A(PUP(BSP(FTP)))].
  555.                                                                  Page 12
  556.  
  557. A NOTE ABOUT LOCAL ADDRESSING
  558.                                  This  section  is  independent of the
  559.                                  previous sections.   One  may  accept
  560.                                  the  previous recommendations without
  561.                                  accepting the recommendations of this
  562.                                  section.
  563.  
  564. It is our feeling that local access scheme in general, and Ethernets  in
  565. particular,  should  NOT  be  treated  as  NETWORKS  which  are globally
  566. registered in the InterNetwork directory of Networks.
  567.  
  568. For sites (1) whose local access network (e.g., the Ethernet) is  NOT  a
  569. registered network and does not have an Internetworkly known Network-ID,
  570. issued  by  Jon  Postel, and (2) are on the ARPAnet, it is proposed that
  571. the 8-bit LOGICAL-ADDRESS field be used as their Ethernet-address.
  572.  
  573. Since the new ARPAnet address (1822,  96-bit  header)  is  in  the  same
  574. format   as   the   IP-address,  this  could  result  in  a  significant
  575. simplification of the gateway implementation.
  576. Hence, the proposed IP- and ARPAnet-address format is as follows:
  577.  
  578. IP:       |<--Network--->|<----- understood only by that network ----->|
  579. ARPAnet:  |<--Network--->|      IMP     |Physical host | Logical host  |
  580.           +--------------+--------------+--------------+---------------+
  581.           | ARPAnet='12  |      IMP     | INTERFACE    | local address |
  582.           +--------------+--------------+--------------+---------------+
  583.                8 bits         8 bits         8 bits        8 bits
  584.  
  585.               (The ARPAnet format is conceptually as shown above,
  586.                    physically it is different, obviously)
  587.  
  588. The third field identifies the IMP/HOST-interface which is used for  the
  589. gateway.    Traditionally  it is called "physical-host", but it does not
  590. identify the host, it identifies only the interface.
  591.  
  592. Obviously, the 8-bits local address cannot  be  sufficient  for  a  long
  593. time,  and  sooner or later more bits will be needed to identify all the
  594. local destinations.
  595.  
  596. Thence, source routing should be used, in the same framework of protocol
  597. nesting.    It  is  important  to  recognize  that  this  will   happen,
  598. eventually,  and  incorporate  this  concept  in  the  design of current
  599. software, even though it is not about to be implemented soon.
  600.  
  601. Note that for sites  which  are  connected  to  the  INE  this  approach
  602. interacts  with  the "multiple-homing" problem, whose solution is beyond
  603. the scope of this note.
  604.  
  605. The multiple-homing problem does not exist for sites which are connected
  606. to the INE via a single gateway, like CMU for example.
  607.                                                                  Page 13
  608.  
  609. (B) Available Hardware/Software
  610.  
  611. NOTE:  this list is a tentative list of hardware and software components
  612. which may be made available by some sites to other members of the group.
  613. This  should  be  treated  as  a  tentative  list,  rather  than  a firm
  614. commitment.  It is always advisable to check with each group  about  the
  615. status of these components before counting on them.
  616.  
  617.    - CMU  will  program  a  PDP11/34  to serve as an IP+PUP gateway
  618.      which is capable of performing the encapsulation of PUP inside
  619.      IP, hence being of type S12, being able  to  communicate  both
  620.      with type-S1 and type-S2 sites.
  621.  
  622.      It  is  expected  that  most of the other sites will duplicate
  623.      this gateway by getting an 11/34 and  importing  the  software
  624.      from CMU.
  625.  
  626.    - CMU  may  be  able  to implement the IP protocol in Dovers and
  627.      Penguins.  PARC will help.
  628.  
  629.    - ISI will implement an efficient PDP10-KL/Ethernet interface.
  630.  
  631.    - ISI  will  implement  a  PDP11-based   terminal   concentrator
  632.      interfaced to an Ethernet.
  633.  
  634.    - MIT  will probably implement IP (but probably not TCP) in MESA
  635.      for the ALTO.
  636.  
  637.    - SU will build microprocessor-based Ethernet  interfaces,  with
  638.      the MCS-68000 (or Z-8000)  and  the IEEE488 bus (GPIB) for the
  639.      HP3000, several HP300's and twelve IBM Series/1's.  Also for a
  640.      VAX system.
  641.  
  642.    - SU will implement a microprocessor-based terminal concentrator
  643.      for the Ethernet.
  644.  
  645.    - SU  plan to interface a PDP10-KL (SAIL) via the 11/40 console.
  646.      Probably the same for a PDP-KI (SUMEX), too.
  647.  
  648.    - PARC  will  be  able to supply both TENEX and TOPS-20 code for
  649.      handling both raw-PUPs and byte-streams, also the higher level
  650.      PUP-based protocols such as FTP,  EFTP,  EMPRESS, PSPOOL, etc.
  651.      This does not include the  level-0  handling  which  obviously
  652.      depends  on  the  exact hardware interface.  Since none of the
  653.      sites is expected to have the same Ethernet interface as  MAXC
  654.      has, the level-0 help is not available.
  655.                                                                  Page 14
  656.  
  657.  
  658. (C) List of participants
  659.  
  660.  
  661. CMU              Bob Sproull     412-578-2621    Sproull@CMUA
  662.  
  663. ISI              Danny Cohen     213-822-1511    Cohen@ISIB
  664.  
  665. MIT              Dave Clark      617-253-6003    Clark@MIT-MULTICS
  666.  
  667. Stanford         Forest Baskett  415-497-1916    FB@SAIL
  668.                  John Seamons    415-497-3236    Admin.jks@SCORE
  669.                  Bill Nowicki    415-497-9437    CSD.Nowicki@SCORE
  670.                  Ron Crane       415-494-4298    Crane@PARC
  671.  
  672. U of Rochester   Ed Burke        716-275-5671    Feldman@SUMEX-AIM
  673.  
  674. Xerox-PARC       Ed Taft         415-494-4419    Taft@PARC
  675.                  Mike Schroeder  415-494-4463    Schroeder@PARC
  676.                  Ron Crane       415-494-4298    Crane@PARC
  677.                  John Shoch      415-494-4384    Shoch@PARC
  678.  
  679.  
  680.  
  681. ========================================================================
  682.  
  683. A personal comment:
  684.  
  685. The main idea of traversing the ARPA-INE with [IP(PUP)] and the division
  686. between host and gateway encapsulation was conceived  during discussions
  687. with Bob Sproull, at CMU.  Bob deserves the credit for getting it right,
  688. but should not be blamed for the details which I managed to mess up.
  689.  
  690. The  meeting  summary was expanded to cover in  detail several technical
  691. issues (especially  addressing)  which  were  sketched  in  the  meeting
  692. without the details which are necessary to make it all work.  Therefore,
  693. putting this note together turned out to be a bigger  effort  than  what
  694. was expected.
  695.  
  696. In  addition,  the note attempts to explain many issues and details in a
  697. way which is (hopefully) clear even to the internetworking-naive reader.
  698. Doing so was a substantial effort which could not have been done without
  699. the help from Jon Postel and Carl Sunshine, and a tremendous  help  from
  700. Ed Taft and John Shoch who pointed  many issues,  corrected many details
  701. and rewrote several sections.  Thank you all.
  702.  
  703. ========================================================================
  704.  
  705.  
  706.  
  707. All comments are welcome,
  708.                                      Cheers,
  709.                                                              Danny.
  710.